1. Field of the Invention
The present invention relates to a data communication system and data receiving and sending terminals, and more particularly to a data communication system which enables real-time output and accumulation of received data concurrently at a data receiving terminal, and such data receiving and sending terminals.
2. Description of Related Art
FIG. 10 of the accompanying drawings is a block diagram showing a data communication system utilizing a TCP/IP (transmission control protocol/internet protocol). The data communication system 100 of FIG. 10 comprises a TCP/IP network 105, which is constructed by a plurality of communication networks 101 each according to TCP/IP and a plurality of routers 102, and a sending terminal 103 and a plurality of receiving terminals 104, which both terminals are connected to the TCP/IP network 105. For example, data of a particular service (e.g., VOD (video on demand)) can be delivered to the plural receiving terminals 104.
When the same data is sent (delivered) from a particular sending terminal 103 to the plural receiving terminal 104 in TCP/IP, it is customary not to increase the data sending amount of the sending terminal 103 even though increasing the number of the receiving terminals 104, employing a technology called “multicast”; sending data is not carried out for each and every receiving terminal 104.
Specifically, each router 102 grasps a network 101 where the terminals 104 to receive multicast data exist (are connected to); as a need arises, the router 102 copies the received multicast data and delivers the copy multicast data to another communication network 101. Accordingly, if the sending terminal 103 send multicast data only once, the multicast data is then copies by a necessary number and transferred at each router 102. Finally, multicast data for a necessary number of the receiving terminals 104 are generated in the TCP/IP network 105 for delivery to the individual receiving terminals 104.
In the TCP/IP network (hereinafter also called “network”) 105, data obtained by the receiving terminal 104 would tend to lack in part as a sending error occurs for various causes during transfer of data. Such data loss in the network 105 can be solved using a resending process protocol (application) in TCP.
However, as shown in FIG. 11, if the data communication system 100 is in the form of an AV (audio and video) data (multimedia data) delivery system where AV data is sent from the sending terminal 103 to a particular receiving terminal 104 via the network 105 and is reproduced with real time and output to a display unit 104a and a speaker 104b at the receiving terminal 104, it is customary that a resending process is not carried out if possible because AV data has the following characteristics:
(1) Since AV data is very large in data amount, the load of data sending of the sending terminal 103 would increase in proportion to the number of receiving terminals 104 when the resending process is repeated. For the same reason, the network band would become heavy in traffic, giving a large influence on other data communications sharing the same network 105.
(2) Since the receiving terminal 104 cannot reproduce AV data until after completion of resending, a great time of delay would occur (meaning of real-time communication would become less significant).
(3) AV data can be treated as practically no problem as long as quality in reproduced image and voice is temporarily lowered by only small degrees despite occurrence of data lacking at the receiving terminal 104.
Therefore, AV data is sent occasionally using a protocol called UDP (user data gram protocol), which is a TCP/IP protocol family and devoid of resending control in method per se. But, even in the case using this UDP, an upper layer (e.g., an application layer) can be equipped with a data resending control function.
Given that the resending control function is thus equipped in data sending in UDP, a resending process would be practically impossible at a single sending terminal 103 when the number of the receiving terminals 104 increases. Consequently, in the multicast technology field, various methods called reliable multicast technologies have been proposed.
One example of such reliable multicast technologies is a method of reducing the frequency of a resending process at the individual sending terminal 103 by collecting resending requests from the individual receiving terminals 104 together temporarily in an apparatus located at the center of the network and then sending these resending requests to the sending terminal 103. Another example is a technology called “local repair” in which an apparatus (e.g., a router 102) located between the sending terminal 103 and the receiving terminal 104 (in the network 105) serves as an agent for the sending terminal 103 to resend requested resending data if the apparatus has such resending data.
In such AV data delivery system 100, when the sending terminal 103 sends the circumstance of a conference or image and voice information of a monitor camera as AV data to the receiving terminal 104 with real time, it is required that the delay time of data from when sent at the sending terminal 103 to when reproduced at the receiving terminal 104 should be reduced to a minimum. Particularly voice data must be sent without interruption; if an interruption occurs in received data, it results in reproduced sound with interruption so that the listener would feel an incompatibility.
However, when the network band is heavy in traffic as another data communication takes place using the same network 105, reduced sound would encounter an interruption at the receiving terminal unless the sending rate (sending data amount) of AV data is lowered, thus increasing the reproduction delay time by the interrupted time.
In order to avoid these circumstances, it is effective to provide the sending terminal 103 with a detector for detecting a possible heavy traffic in the network band to be used in transfer of AV data, and to control the sending rate of AV data at the sending terminal 103 when a usable band is narrowed.
Assume that the sending terminal 103 compresses and encodes voice data by sampling normally at 44.1 kHz and then sends the resulting voice data in 2 channels on stereo (256 kbps). During this data sending, when the sending terminal 103 has detected that the network band usable between the sending terminal 103 and the receiving terminal 104 has been narrowed, the sending terminal 103 downgrades the quality of the sending data stepwise from 2 channels on stereo (128 kbps) to monophonic (64 kbps).
Since the sending data amount from the sending terminal 103 is thereby reduced, it is possible to prevent any delay in reduced voice at the receiving terminal 104. Further, since the sending-data quality is downgraded stepwise, it is possible to have the listener be unconscious of changes in quality. Otherwise when the traffic of the network 105 restores, the sending-data quality is upgraded stepwise so that the data is reduced in original quality.
The above-mentioned method of reducing the sending data amount as the usable network band is narrowed is exemplified by Japanese Patent Laid-Open Publication No. HEI 7-75092, which discloses a method of reducing the resolution of motion image data with the sending rate kept unchanged. Namely, when the usable network band is narrowed, high-frequency components are cut off motion image data to be sent, thus restricting the range of frequency components of the sending data to reduce the sending-data amount per unit time.
Whether or not the network band usable in data sending has been narrowed (or widen) can be discriminated by measuring changes in the sending delay amount between the sending terminal 103 and the receiving terminal 104. As an example of this measuring method, it is known to utilize SR/RR (sender report/receiver report) packets in RTCP (real-time control protocol), which is a data transfer protocol family called RTP (real-time transport protocol). How to measure the sending delay will now be described with reference to FIG. 12.
First of all, the sending terminal 103 sends data called an SR (sender report) packet 112 periodically in parallel to sending ordinary AV data (packet) 111. In this SR packet 112, time information, indicating the time at which the SR packet 112 was sent from the sending terminal 103, is stored.
Upon receipt of the SR packet 112, the receiving terminal 104 generates an RR (receiver report) packet 113 in response to the SR packet 112 and sends (returns) the RR packet 113 to the sending terminal 103. At that time, the receiving terminal 104 stores in the RR packet 113 two kinds of information, i.e., (a) SR-packet-sending-time information stored in the SR packet 112 and (b) delay-time information indicating a period of time lapsed in the receiving terminal 104 from when the receiving terminal 104 received the SR packet 112 until when the receiving terminal 104 sends the RR packet 113 in response to the SR packet 112.
Finally, upon receipt of the RR packet 113 from the receiving terminal 104, the sending terminal 103 can obtain a round-trip sending-delay amount between the sending terminal 103 and the receiving terminal 104 by calculating the receiving time based on the following equation:(round-trip sending-delay amount)=(RR-packet receiving time)−(SR-packet sending time stored in RR packet 113)−(delay time stored in RR packet 113)
Based on changes in the thus obtained round-trip sending delay amount between the sending terminal 103 and the receiving terminal 104, it is possible to discriminate whether or not the network 105 being used in sending AV data is becoming heavy in traffic. Further, by controlling the sending rate in such a manner that this sending delay amount is in a not-excessively-varying, stabilized state, it is possible to keep the reproduction delay time at the receiving terminal.
Then, in the above-mentioned AV data delivery system 100, as shown in FIG. 13, AV data received by a particular receiving terminal 104 is accumulated in an accumulating medium (received-data accumulating section) 104c, such as in the form of HDD (hard disc drive). Applications for taking out the accumulated AV data for reproduction and editing will be described later. The terminal(s) that accumulate the received AV data are one or more of all the receiving terminals 104.
This system construction is advantageous in a monitor system in particular. Namely, the sending terminal 103 sends data taken by a video camera installed at a monitoring point, and images and sounds reproduced with real time are monitored usually at the individual receiving terminals 104. When the occurrence of an abnormality has turned out, the receiving terminal 104 can subsequently reproduce to parse accumulated image and sound of the received data, which are accumulated in the accumulating medium 104c. Though illustration is omitted in FIG. 13, the same number of sending terminals 103 as that of the monitoring points are actually connected to the network 105.
However, also this monitoring system occasionally encounters a problem in that the receiving terminal 104 accumulating the received data would become unable to receive data in the originally required quality if the sending quality is changed at the sending terminal 103 in conformity with the traffic of the above-mentioned network 105 in an effort to improve the reproduction delay time at the receiving terminal 104.
This is true because, if the data is to be temporarily accumulated for subsequent use, it absolutely requires the condition that the originally necessary quality is kept throughout the entire data; though in real-time reproduction, as mentioned above, change in sound from stereo to monophonic or in encoding/sending rate from 256 kbps to 128 kbps would cause the reproduction quality to be downgraded only temporarily so that not-so-keep listeners would not feel an incompatibility.
Since the above-mentioned resending control function is originally to request for resending quite the same packet as the lost packet in the occurrence of a packet loss, it is impossible to make a resending request in accordance with such quality change.